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I.  INTRODUCTION 


A.  BACKGROUND 

As  Air  Force  Financial  Management  (FM)  Officers,  we  value  the  ability  to 
provide  near  real-time  decision-quality  information  to  those  we  serve.  We  value 
flexibility.  And,  we  value  the  people  who  do  the  work  and  their  innovative  potential. 
These  values,  and  the  application  they  find  in  the  Micro  Solution  development  approach, 
directly  support  the  USAF  Transformation  Flight  Plan’s  focus  on  our  business  processes: 

Air  Force  business  processes  stem  from  an  industrial  age  when  America  faced  a 
security  environment  that  was  vastly  different  in  character  than  the  one  the  Air  Force 
faces  today.  Although  they  have  been  incrementally  reformed  and  modernized  over  the 
last  30  years,  the  underlying  philosophy  and  basic  architecture  of  these  processes  have 
not  changed-they  are  labor  intensive,  they  lack  agility,  flexibility,  and  speed. 
Accountability  is  fragmented  and  diluted  throughout  large  bureaucracies  that  must 
render  their  collective  assent  to  enable  the  accomplishment  of  the  most  mundane  tasks. 

The  principal  goal  of  business  transformation  is  to  fashion  fast,  flexible,  agile, 
horizontally  integrated  operational  support  processes  that  enable  fast,  flexible,  agile,  and 
lethal  combat  forces.  The  key  to  this  goal  is  focusing  on  warfighter  needs  and 
eliminating  the  seams  that  divide  Air  Force  capabilities  today.  The  Air  Force  envisions  a 
further  business  environment  that  provides  fast,  predictive  operational  support  and 
response  through  situationally  aware  commanders.  The  secondary  goal  of  business 
transformation  is  to  achieve  increased  efficiencies  through  better,  simplified,  integrated 
processes  and  better  support  tools.  Improved  efficiency  of  business  process  should 
deliver  the  following  effects: 

-  A  twenty  percent  shift  in  business  operations  resources  (dollars  and  people )  to 
combat  operations  and  new/modern  combat  systems 

-A  working  load  enabling  its  people  to  conduct  routine  (non-crisis,  non-exercise ) 
organizational  missions  safely  within  a  40  -to  -  50  hour  work  week. 

-  A  compression  of  average  process  cycle  times  by  a  factor  of  four  ( relative  to 
current  established  process  baseline). 
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-  The  empowerment  of  personnel  and  enrichment  of  job  functions  d 


These  very  specific  transformation  mandates  are  highly  relevant  to  Financial 
Management  operations.  Meaningful  analysis  in  the  FM  field  requires  the  ability  to 
compile  and  reconcile  data  from  different  systems.  Legacy  system  outputs  are  notably 
inflexible,  and  many  analysts  are  bogged  down  in  tasks  related  to  simply  moving  data 
around  with  little  time  left  for  critical  thinking.  While  many  ‘enterprise-wide’  tasks 
could  be  automated  the  expense  of  formal  automation,  by  means  of  a  contracted  agent,  is 
often  prohibitive.  Even  modem  COTS-based  Financial  Software  implementations  often 
require  temporary  solutions  to  bridge  gaps  in  initial  operating  capability.  While  these 
systematic  solutions  resolve  performance  and  integration  issues,  they  also  drive 
tremendous  process  changes  -  requiring  more  flexibility  and  innovation  than  ever  before. 
FM  professionals,  not  systematic  solutions,  bring  innovation  to  the  fight. 

The  authors  have  sixteen  years  of  collective  service  in  the  Air  Force  FM 
community;  including  tours  in  Budget  Operations,  Financial  Services,  Cost  Analysis, 
Project  Management,  and  Legacy  Systems  support.  Experience  suggests  that  in  many 
cases,  particularly  those  in  which  requirements  are  well  understood  and  solution  scope  is 
limited,  important  ‘desktop’  development  work  is  within  the  reach  of  FM  professionals. 
Unfortunately  advanced  software  application  training  and  support  is  not  a  priority  in  the 
FM  community.  The  few  FM  application  developers  working  in  the  field  today  are 
typically  self-taught,  and  their  efforts  are  usually  focused  on  organizationally -unique 
solutions.  FM  analysts  are  generally  expected  to  wait  for  IT  professionals  to  deliver  FM 
community  solutions  downstream  meanwhile  patching  together  processes  to  meet  daily 
requirements. 

Excel  VBA  in  the  hands  of  an  FM  functional  expert  offers  a  low-cost,  task-precise 
approach  to  developing  relevant  solutions  and  task  automation  tools.  But  when  does  it 
make  sense?  Can  the  value  of  this  grass-roots  development  approach  be  quantified? 


1  USAF  Transformation  Flight  Plan,  6  Jan  2005.  Accessed  31  Oct  2005,  available  from 
http://www.oft.osd.mil/library/libraryfiles/document_385_2004_USAF_Transformation_Flight_Plan.pdf. 
Internet . 
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How  attractive  is  it  really?  Which  projects  are  most  worth  doing?  The  purpose  of  the 
Micro  Solution  Development  Model  is  to  address  those  questions  with  objective, 
quantifiable  answers. 

B.  THE  \N  EXCEL  VBA  DEVELOPMENT  ENVIRONMENT 

MS  Visual  Basic  (VB)  is  an  object-oriented  programming  language  used  to  build 
Windows-based  applications.  MS  Visual  Basic  for  Applications  (VBA)  is  a  powerful 
software  development  environment  resting  on  each  of  the  individual  Microsoft  Office 
applications  (Access  VBA,  Excel  VBA,  etc.).  Excel  VBA  differs  from  Visual  Basic  in 
that  it  is  designed  to  work  within  the  framework  of  the  Excel  application’s  functionality, 
while  retaining  the  capabilities  of  the  VB  language  as  well.  Figure  1  highlights  some  key 
features  and  functions  commonly  used  in  Excel  VBA  development.  The  VBA  language 
was  first  included  as  a  standard  feature  in  Excel  with  version  5  (1994)2,  and  comes 
standard  with  the  current  Air  Force  desktop  software  package,  MS  Office  2003. 


Leveraging  Excel  Capability 

Features  Functions 


■  C  opy  and  P  aste/P  aste  Sp  e  cial 

■  Insert  and  Delete 

■  F  ormatting 

■  Conditional  Formatting 

■  Sort  and  Subtotals 

■  AutoFilters 

■  Naming  Ranges 

■  Find  and  Rep  lac  e 

■  Data  Validation 

■  Freeze  and  Split  Frames 

■  Ctrl/Move  and  Ctrl/ShifVMove 

■  Quantitative  Analysis 


■  SUM,  AVG 

■  IF  (Nest  up  to  seven) 

■  RIGHT,  LEFT,  MID 

■  VLOOKUP 

■  CONCATENATE 

■  ISERROR,  ISBLANK,  ISTEXT 

■  COUNTIF,  SUMIF 

■  MAX,  MIN 

■  TODAY,  DAY,  MONTH 

■  MATCH 
•  RAND 


Figure  1.  Features  and  Functions  Useful  in  Excel  VBA  Development 


-  Walkenbach,  John,  Excel  2000  Power  Programming  with  VBA.  New  York:  Hungry  Minds  Inc., 
1999. 
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Excel  VBA  allows  the  user  to  create  macros  or  programs  which  perform  tasks 
from  within  the  host  application.  So  instead  of  writing  a  procedure  to  sort  records,  the 
Excel  VBA  developer  records  a  macro  from  Excel  environment  sorting  the  records  to 
their  requirements  using  the  existing  Excel  Data/Sort  capability  (object).  Though  Excel 
objects  come  with  constraints  (sorting,  for  example,  is  limited  to  three  levels),  developing 
automated  solutions  on  top  of  Excel  capabilities  jump  starts  development. 

VBA  essentially  opens  programming  to  a  new  class  of  developer.  This  is  the 
primary  advantage  Excel  VBA  offers  would-be  EM  application  developers,  who 
generally  have  years  of  spreadsheet  experience  and  are  well-versed  in  Excel  capabilities. 
Excel  VBA  also  offers  the  advantage  of  being  widely  available  at  no  additional  cost, 
since  it  is  installed  and  resides  with  the  Excel  application  (standard  desktop  software). 
Once  a  solution  is  developed  and  tested,  it  can  be  easily  shared  in  the  form  of  an  Excel 
workbook.  Finally,  VBA  provides  the  means  to  go  beyond  the  capabilities  of  Excel  —  to 
include  writing  and  securing  customized  functions,  employing  decision  loops,  and 
automating  complex  task  sequences. 

C.  DEFINING  MICRO  SOLUTION  DEV  ELOPMENT 

For  the  purpose  of  this  report,  solution  opportunities  considered  ‘Micro’  in  nature 
will  involve  automation  of  tasks  involving  reconciliation,  translation,  analysis,  or 
reporting  of  existing  legacy  data,  or  some  combination  thereof.  Though  the  field  cases 
presented  in  Section  III  will  vary  greatly  in  complexity,  the  predictive  qualities  of  the 
development  model  are  designed  to  work  within  a  fairly  narrow  scope  of  development 
work  (as  defined  by  the  model’s  input  variable  boundaries).  Important  characteristics  of 
the  Micro  Solutions,  as  presented  in  this  report,  are  outlined  in  Figure  2. 
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Micro  Solutions  Defined 

•  Low  to  moderate  complexity 

•  Solutions  that  “bridge”  gaps 

•  Developed  in  days  or  weeks 

•  One-year  life  cycle 

•  Developed  by  and  for  FM  personnel 

Figure  2.  FM  Micro  Solution  Characteristics 

Micro  Solution  candidates  are  potential  development  projects  of  low  to  moderate 
complexity.  They  might  be  thought  of  as  tactical  solutions,  since  they  address  procedures 
and  processes  at  the  task  level.  If  two  people  can’t  get  their  arms  completely  around  the 
solution  requirements  in  30  minutes  or  less  of  discussion,  it’s  not  a  Micro  Solution. 
Micro  Solutions  are  NOT  designed  to  replace  legacy  system  data  or  reports;  they  simply 
make  relevant  information  available  much  more  quickly.  A  typical  solution  will  take  a 
few  days  or  weeks  to  develop,  and  will  reduce  a  series  of  tasks  that  once  took  minutes  or 
hours  into  seconds.  The  development  model  assumes  the  solution  is  perishable,  relevant 
for  no  more  than  one  year.  Micro  Solutions  are  indeed  short-term  solutions. 

Probably  the  most  important  difference  between  the  development  discussed  in  this 
report,  and  more  traditional  approaches  to  application  development,  is  the  person  doing 
the  work.  The  Micro  Solution  approach  actually  allows  for  the  FM  professional  (who  is 
likely  to  have  far  more  functional  experience  than  software  development  experience)  to 
take  the  role  of  the  developer.  FM  professionals  already  understand  the  analytical 
requirements,  the  business  rules,  and  the  best  way  to  present  the  information.  FM 
professionals  probably  understand  the  detailed  steps  needed  to  make  solutions  work  in 
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the  Excel  environment.  But,  of  course,  they  need  training  and  on-going  support  initially 
to  become  proficient  in  the  VBA  development  environment.  More  specific  assumptions 
about  roles  and  process  are  discussed  in  Section  II. 

D.  PROJECT  METHODOLOGY 

The  Micro  Solution  Development  Model  is  central  to  the  project  because  it 
attempts  to  properly  consider  the  most  important  aspects  of  the  development  scenario, 
synthesizing  the  variables  and  assigning  an  objective  value  to  the  work.  So,  before  any 
observations  or  conclusions  are  drawn,  the  model  itself  will  be  thoroughly  outlined  and 
explained.  The  fundamental  ‘input’  variables  (Development  Costs  and  Savings  Factors) 
are  discussed,  then  calculation  of  the  outputs  (ROI,  Payback  Period,  and  Savings)  are 
explained  in  some  detail.  With  this  foundation  in  place  the  methodology  used  to  derive 
the  software  development  Growth  Factor  is  mapped,  including  application  of  Unit 
Fearning  Curve  Theory  and  treatment  of  additional  input  variables.  The  Growth  Factor  is 
used  in  the  model  to  account  for  unforeseen  problems  or  requirements  by  burdening  labor 
estimates  (by  degree)  before  output  values  are  calculated. 

The  project  then  applies  the  Micro  Solution  Development  Model  to  six  field- 
developed  solutions,  to  assess  value  in  retrospect  and  draw  conclusions.  Captain  O’Hare 
was  involved  directly  or  indirectly  in  the  development  of  these  case  solutions  -  therefore, 
model  input  data  for  each  case  is  therefore  based  on  first-hand  knowledge  of  actual 
resources  required  to  complete  the  work.  Captain  Krott,  a  Financial  Services  Officer 
(FSO)  with  experience  employing  the  community  solutions  presented,  offers  a  ‘field 
customer’  perspective.  The  presentation  and  analysis  of  each  case  thus  includes  both 
quantitative  and  qualitative  aspects;  the  model  inputs  and  outputs,  of  course,  as  well  as  a 
brief  discussion  of  the  important  factors  driving  development  and  the  results  experienced 
in  operations. 

Next  the  project  will  apply  the  Micro  Solution  Development  Model  to  two 
potential  development  cases.  The  input  variables  and  Growth  Factor  considerations  for 
each  case  are  presented  and  discussed.  Analysis  of  the  model  outputs  will  include  some 
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what-if  scenarios  to  shed  light  on  sensitive  inputs  and  to  draw  conclusions  about  the 
profitability,  in  terms  of  ROI  and  Payback  Period,  of  the  Micro  Solution  development 
approach  in  a  broader  sense. 

Finally,  the  project  will  present  specific  recommendations  consistent  with  the 
conclusions  drawn  from  application  of  the  model.  This  professional  report  makes 
extensive  use  of  Figures,  actually  screen  snapshots  of  the  model  itself  under  various 
conditions,  to  aid  in  the  illustration  of  report  content.  A  copy  of  the  Micro  Solution 
Development  Model  in  the  form  of  an  Excel  workbook  file: ExcelVBA_Model.xls),  is 
provided  as  an  attachment  to  this  report. 
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II.  THE  MICRO  SOLUTION  DEVELOPMENT  MODEL 


A.  MODEL  METHODOLOGY 

The  Micro  Solution  Development  Model  (MSDM),  as  shown  in  Figure  3,  is 
assembled  and  mn  from  an  Excel  workbook,  and  is  divided  into  the  following:  Inputs: 
including  Development  Cost  Factors,  Savings  Factors,  Characteristics,  and  Outputs; 
Return  on  Investment,  Payback  Period,  and  Savings.  Regions  are  outlined  and  assigned 
distinct  colors  for  ease  of  reference  throughout  the  report. 


Name  of  Micro  Solution  (Example) 


INPUTS 


Development  Cost  Factors 
1  Functional  Labor  Rate  (hourly) 
Developer  Labor  Rate  (hourly) 
Basis  for  Requirements 
Functional  Time  Required  (hours) 
Developer  Time  Required  (hours) 
juser  Training  Required  (hrs/user) 


Grade 

GS-12 

E-7 


Past  Actual 


S47.63 

$39.35 


Development  Savings  Factors 
Current  Task  Time  (minutes) 
|current  Task  Frequency  (per  week) 
dumber  of  Users  Tasked 
lUser  Labor  Rate  (hour 


E-4 


[Development  Characteristics 
j  Developer  VBA  Experience 
|  Developer  Excel  Application  Experience 
|  Developer  Functional  Experience 
Solution  Type 
Solution  Requirements 


■xterss&od  and  Defim 


Growth  Factor  »> 


OUTPUTS 

Return  on  Investment  (in  one  year) 

563% 

Payback  Period  (days) 

55 

Savings/Use 

$12.55 

Annual  Savings 

$3,325 

Figure  3.  Micro  Solution  Development  Model 
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The  user  of  the  model  enters  the  proposed  solution  development  data  into  the  grey 
colored  fields,  paying  strict  attention  to  the  unit  basis  for  entry  of  each  variable.  Note  the 
distinction  between  light  and  dark  grey  areas.  The  dark  grey  areas  are  variables  that  must 
be  selected  from  a  list  of  drop-down  menu  options  (the  drop-down  arrow  appears  when 
the  appropriate  cell  in  the  worksheet  is  selected).  Drop-down  lists  are  used  in  the  model 
to:  1)  provide  a  standard  hourly  rate  lookup  for  the  labor  rate  fields,  based  on  grade 
selection;  2)  select  the  Basis  for  Requirements;  and  3)  limit  selection  criteria  in  the 
Development  Characteristics  region  and  thus  bound  the  development  context.  The  model 
simply  updates  the  output  values  based  on  current  input  criteria. 


B.  ASSUMPTIONS 

Achieving  a  level  of  reasonable  objectivity  was  a  primary  consideration  in 
construction  of  the  Micro  Solution  Development  Model.  Still,  along  the  way  the  authors 
realized  they  would  need  to  make  a  number  of  assumptions  about  the  development 
situation  being  evaluated.  In  order  to  provide  the  best  possible  understanding  of  the 
outputs  presented  by  the  model,  the  most  important  of  these  assumptions  are  discussed  in 
the  following  paragraphs . 

1.  Horizon 

It  was  decided  early  on  that  the  model  would  be  used  to  evaluate  short-term 
solutions,  that  is,  solutions  with  an  assumed  field  life  of  no  more  than  one  year.  Though 
many  of  the  FM  Micro  Solutions  deployed  in  the  field  have  remained  relevant  for  years, 
the  model  was  limited  to  a  single  year  for  several  reasons.  First,  the  solutions  are 
designed  to  be  effective  interim  tools,  not  to  replace  or  offset  the  need  for  systematic 
solutions  (though  they  may  be  useful  in  identifying  future  requirements).  Second,  the 
operational  FM  environment  where  these  solutions  are  developed  and  fielded  is 
increasingly  subject  to  change.  And  third,  using  a  one  year  time  frame  adds  an  element 
of  conservatism  to  the  model  while  emphasizing  the  agile  nature  of  Micro  Solutions. 
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2.  Solution  Runtime 

Because  Excel  VBA  executes  even  complex  task  sequences  (100+  Excel 
commands)  against  thousands  of  records  in  seconds,  the  model  assumes  the  solution 
runtime  to  be  zero.  This  is  not  actually  correct,  since  it  may  take  a  few  moments  to  open 
the  solution  file,  initiate  the  task  routine,  perhaps  select  file(s)  for  input,  etc.  But  given 
our  purpose  to  determine  the  first  order  value  of  Micro  Solution  development  in  a  given 
situation,  with  a  reasonable  level  of  objectivity,  iiese  few  seconds  were  considered 
immaterial. 


3.  Roles 

The  model  assumes  that  the  development  work  is  primarily  accomplished  by  a 
two -person  team  of  FM  professionals;  the  Developer  and  the  Functional.  Though  others 
may  be  involved  indirectly,  these  two  take  responsibility  for  understanding  the 
requirements  and  delivering  a  quality  solution.  The  Micro  Solution  development  context 
assumes  these  two  individuals  are  willing  participants,  understand  their  roles,  work 
together  well,  are  relatively  tech-savvy,  have  a  desire  to  leam,  and  will  be  provided  the 
time  and  space  needed  to  see  the  development  effort  through. 

The  Developer  would  be  specifically  responsible  for  outlining  the  project, 
handling  all  the  coding  and  debugging  work  in  the  VBA  environment,  and  ensuring  the 
solution  is  “sturdy”  enough  for  everyday  use.  In  the  context  of  this  project  the  Developer 
is  likely  to  have  functional  experience  and  must  have  a  strong  background  in  Excel,  but 
may  have  no  formal  training  in  software  development  processes  and  applications.  The 
Functional,  usually  in  a  position  to  supervise  the  task  being  automated,  must  understand 
the  task(s)  well  enough  to  communicate  the  requirements,  validate  the  business  rules,  and 
ensure  comprehensive  testing  of  the  solution  in  the  operational  context. 

4.  Requirements  Definition  Process 

Another  important  assumption  involves  the  requirements  definition  process, 
which  is  assumed  to  be  brief  and  informal.  This  is  where  Micro  Solution  development 
has  a  clear  advantage  over  other  development  approaches,  since  both  team  members 
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should  have  a  clear  understanding  of  what  is  required.  Still  documentation  is  important 
in  this  early  stage,  if  for  no  other  reason  than  to  express  what  the  solution  will  and  will 
not  do.  The  basic  process  involves  the  Developer  and  Functional,  a  white  board  and 
some  working  markers,  and  a  quiet  place  (computers  ire  a  distraction  at  this  point). 
Basically,  if  the  principals  involved  can’t  map  the  entire  solution  out  on  a  whiteboard  in 
thirty  minutes  or  less  it’s  not  a  Micro  Solution  candidate.  However  —  if  the  proposed 
solution  can  be  mapped  from  start -to-finish,  and  the  Developer  is  comfortable  with  the 
Excel  and  Excel  VBA  capabilities  that  will  be  necessary,  the  map  becomes  the  basis  for 
estimating  time  (labor)  required. 

5.  Training  and  Support  Concept 

Perhaps  the  most  important  assumption  has  to  do  with  the  level  of  training  and 
support  afforded  the  novice  Developer,  training  and  support  that  is  very  limited  in  actual 
practice.  Hie  context  of  Micro  Solution  development  assumes  the  Developer  has  taken 
the  opportunity  to  attend  an  entry  level  Excel  VBA  training  course.  At  a  minimum  this 
course  would  enable  the  novice  Developer  to  1)  become  comfortable  with  the  functions 
and  capabilities  of  the  VBA  environment,  2)  become  proficient  in  leveraging  key  Excel 
features  and  functions  (as  presented  in  Figure  1),  and  3)  become  familiar  with  extended 
VBA  features  relevant  to  Micro  Solution  development.  The  model  also  assumes  the 
novice  Developer  has  direct  access,  via  email  and  phone,  to  an  experienced  VBA 
Developer  in  the  field  who  can  assist  them  in  designing  the  project  initially  and  help  them 
overcome  challenges  while  working  toward  completion  of  their  first  project. 

C.  INPUT  VARIABLES 

1.  Labor  Rates 

The  model  requires  labor  rates  for  the  Functional,  Developer,  and  User  roles  in 
order  to  compute  development  costs  and  savings.  The  model  utilizes  a  lookup  function  to 
pull  the  appropriate  hourly  rate,  as  described  in  the  following,  once  the  grade  for  each 
role  is  selected  from  the  drop  down  menu  provided. 
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Military  labor  costs  are  based  on  published  DoD  Military  Personnel  Composite 
Standard  Pay  and  Reimbursement  Rates,  Department  of  the  Air  Force,  FY2005,  and  an 
assumed  work  year  of  2,080  hours3.  The  Annual  DoD  Composite  Rates  must  be  used 
when  determining  cost  of  military  personnel  in  management  studies.  These  are  the  same 
fully  burdened  rates  that  would  be  used  to  bill  other  DoD  agencies  for  services,  and  they 
include;  average  basic  pay  plus  retired  pay  accrual,  medical  health  care  accrual,  basic 
allowance  for  housing,  basic  allowance  for  subsistence,  incentive  and  special  pay, 
permanent  change  of  station  expenses,  and  miscellaneous  pay. 

The  best  Civilian  Personnel  Pay  Tables  available  at  the  publishing  of  this  report 
were  FY2005  tables;  therefore  FY2005  rates  were  used  as  a  basis  for  both  military  and 
civilian  hourly  costs.  Civilian  Personnel  Pay  Rates  are  derived  from  Salary  Table  2005- 
SF,  assuming  locality  Pay  for  the  SAN  JOSE- SAN  FRANCISCO -OAKLAND,  CA  (NPS 
local)  area4.  Hourly  rates,  based  on  applicable  Grade  at  Step  05  (mid-tier  Step),  are  then 
burdened  with  an  additional  28.1%  to  account  for  Civilian  Personnel  fringe  benefits  that 
would  be  chargeable  to  other  DoD  components5. 

2.  Other  Development  Cost  Factors 

The  Basis  for  Requirements  field  is  used  to  indicate  use  of  the  model  in  either 
evaluating  completed  projects  (Past  Actual),  as  shown  in  Figure  3,  or  to  estimate  future 
work  (Future  Estimate).  When  Past  Actual  is  selected  as  the  Basis  for  Requirements  the 
growth  factor  displays  None  Applied.  When  Future  Estimate  is  selected  the 
Development  Characteristics  are  activated  and  the  growth  factor  is  used  to  burden  the 
work  estimates  (both  Developer  and  Functional)  appropriately. 

The  Time  Required  (hours)  entries  for  the  Developer  and  Functional  personnel 
are  critical  in  determining  the  model’s  outcome.  Thus,  every  effort  should  be  made  to 

3  Office  of  the  Under  Secretary  of  Defense  (Comptroller).  Accessed  31  Oct  2005,  available  from 
http://www.dod.mil/comptroller/rates/fy2005/2005_k.pdf.  Internet. 

4  Civilian  Personnel  Pay  Rate  Table,  2005.  Accessed  31  Oct  2005,  available  from 
http://www.opm.gov/oca/05tables/indexGS.asp.  Internet. 

5  Civilian  Personnel  Fringe  Benefit,  Fiscal  Year  2005.  Accessed  31  Oct  2005,  available  from 
http://www.dod.mil/comptroller/rates/fy2005/2005_d.pdf.  Internet. 
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ensure  these  numbers  are  as  grounded  as  possible.  The  requirements  ‘map’,  discussed 
earlier,  should  be  used  to  break  the  solution  into  functional  blocks  for  estimating 
purposes  and  the  ‘Novice’  Developer  should  seek  assistance  before  making  an  estimate 
determination.  The  Functional  hours  required  will  consist  primarily  of  developmental 
and  operational  testing,  usually  easier  to  estimate  than  Development  work.  The  User 
Training  is  simply  an  estimate  of  the  time  required  to  familiarize  EACH  functional  user 
with  the  completed  solution. 

3.  Other  Savings  Factors 

The  Development  savings  factors  center  around  the  characteristics  of  the  current 
task,  since  the  idea  of  the  Micro  Solution  is  to  eliminate  any  manual  steps  required  in  the 
current  process.  Again,  the  model  output  and  subsequent  analysis  are  largely  dependent 
on  the  data  provided  in  this  section  and  every  effort  should  be  made  to  ensure  the 
accuracy  of  the  data.  For  example  the  Current  Task  Time  should  be  provided  by  a  User 
who  actually  performs  the  task  day-to-day,  based  on  timing  of  an  actual  task  sequence 
using  current  procedures.  If  the  solution  is  being  considered  as  a  community  solution 
candidate,  then  the  task  time  should  be  adjusted  to  normalize  at  a  typical  task  time  in  a 
typical  organization. 

The  Current  Task  Frequency  indicates  the  number  of  times  per  week  the  current 
task  should  be  performed  in  operations.  Note  that  in  some  cases  this  may  differ  from  the 
frequency  at  which  the  task  is  currently  being  performed ,  especially  if  the  task  time 
makes  frequent  performance  prohibitive.  The  Number  of  Users  Tasked  is  the  number  of 
users  tasked  per  organization  times  the  number  of  organizations  assumed  to  benefit  from 
the  solution.  This  assumption  has  a  great  potential  to  color  the  analysis,  as  we  will 
explore  in  the  case  studies  presented  in  this  report,  so  conservatism  is  important.  For 
example,  before  assuming  all  the  Resource  Advisors  in  a  Wing  will  benefit  from  a 
solution  one  must  ensure  the  solution  is;  1)  relevant  to  their  duties,  2)  widely  available,  3) 
sponsored  by  FM  leadership,  and  4)  supported  with  training  and  follow-up.  The  same 
concerns  must  be  addressed  from  a  broader  perspective  before  assuming  a  solution  will 
benefit  users  across  the  Air  Force  FM  community. 
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Finally,  it  should  be  noted  that  the  User  role,  as  defined  by  the  model,  is  not 
meant  to  designate  a  particular  person.  Instead,  the  grade  selected  for  “User  Labor  Rate” 
should  be  representative  of  those  typically  tasked  with  performing  the  activities 
facilitated  by  the  solution. 


D.  MODEL  OUPUTS 

1.  Return  on  Investment 

In  the  world  of  business  Return  on  Investment  (ROI)  is  used  to  determine  whether 
a  proposed  investment  is  wise,  and  how  well  it  will  repay  the  investor.  It  is  calculated  as 
the  ratio  of  the  amount  gained  (taken  as  positive)  or  lost  (taken  as  negative),  relative  to 
the  basis  of  investment.  The  Micro  Solution  Development  Model  uses  ROI  to  determine 
if  a  proposed  project  is  a  wise  investment  of  time.  This  concept  of  optimum  resource 
utilization  is  the  driving  measure  of  the  model,  though  labor  inputs  are  quantified  in  labor 
dollars  to  accommodate  the  ROI  calculation. 

For  the  purpose  of  this  model  the  amount  gained  (or  lost)  is  the  savings  the 
solution  will  provide,  in  labor  dollars,  and  the  basis  of  investment  is  the  development 
costs.  The  ROI  calculation  in  the  model  uses  is  based  on  the  arithmetic  return  approach: 
ROI  =  (Annual  Savings  -  (Development  +  Training  Costs))  /  (Development  +  Training 
Costs).  Thus,  a  positive  ROI  means  the  solution  would  be  profitable  within  one  year.  An 
ROI  of  100%  means  that  the  savings  in  the  course  of  a  year  are  twice  the  cost  of 
development  and  training.  An  ROI  of  1,000%  translates  to  savings  of  ten  times  the  cost 
of  development  over  the  course  of  a  year. 

However,  because  DoD  decision  makers  tend  to  think  in  terms  of  available 
resources,  as  opposed  to  return  on  resources,  the  ROI  measure  presents  difficulties. 
Comparing  one  potential  development  project  to  another  is  straightforward  using  the 
model,  but  what  about  comparing  the  ROI  results  presented  in  the  model  with  other 
pressing  tasks?  And  when  competing  work  MUST  be  done,  what  is  the  ‘tipping  point’ 
for  committing  valuable  resources  to  a  development  project?  What  about  a  potentially 
‘high-leverage’  solution  (exceptionally  high  ROI)  in  which  the  benefit  falls  largely 
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outside  the  decision-maker’s  organization,  as  in  the  case  of  a  community  solution? 
Clearly  difficult  questions  such  as  these  must  be  addressed  if  the  Air  Force  is  to  achieve  a 
four-fold  compression  in  average  business  process  cycle  times. 

2.  Payback  Period 

The  Payback  Period  is  the  length  of  time  required  to  recover  the  initial  investment 
or,  in  the  case  of  our  model,  how  many  days  it  takes  for  a  developed  solution  to  pay  for 
itself  once  it’s  fielded  (development,  testing,  and  training  complete).  The  idea,  again,  is 
to  provide  the  decision  maker  with  a  meaningful  way  to  understand  the  value  of  potential 
development  work  The  Payback  Period  calculation  in  the  model  is  as  follows:  Payback 
Period  =  (Development  +  Training  Costs)  /  (Daily  Savings). 

This  measure  already  has  an  established  precedence  in  the  Air  Force;  the  Fast 
Payback  Capital  Investment  Program  (FASCAP)6,  which  has  been  using  the  Payback 
Period  as  a  watermark  for  operations -level  investments  since  1991.  The  program 
encourages  organizations  to  compete  for  funds  to  finance  capital  investments  in  facilities 
and  equipment,  and  will  only  consider  investments  where  the  Payback  Period  is  less  than 
two  years.  Using  the  same  approach  at  the  task  level  the  Micro  Solution  Development 
Model  is  designed  to  identify  development  work  where  the  Payback  Period  is  as  short  as 
possible,  often  less  than  90  days. 

3.  Savings 

Since  ROI  and  Payback  Period  are  rather  abstract  units  of  measure,  we  decided  it 
best  to  include  Savings  as  a  model  output.  Savings/Use  is  simply  the  amount  saved  (User 
Labor  Rate  *  Current  Task  Time)  with  each  run  of  the  solution  once  it  has  been  fielded, 
and  after  development  costs  have  been  fully  recovered.  The  Annual  Savings  output,  by 
contrast,  accounts  for  the  development  costs:  Annual  Savings  =  Annual  Savings  - 
(Development  +  Training  Costs). 


6  Air  Force  Policy  Directive  38-3,  Nov  1998.  Accessed  31  Oct  2005,  available  from  http://www.e- 
publishing.  af.mil/pubfile s/af/3 8/afpd3 8- 3/afpd3 8-  3 .pdf.  Internet . 
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In  the  end,  the  Savings  metric  probably  does  the  best  job  of  presenting  a  business 
case  for  Micro  Solution  development,  though  the  dollar  amounts  suggested  are  not 
actually  a  reduction  in  disbursements.  The  Savings  amounts  are  instead  are  a  monetary 
measure  of  the  labor  saved  by  implementation  of  the  solution,  so  they  too  are  a  measure 
of  time. 

E,  ESTIMATING  FUTURE  DEVEUOPMENT  TIME  AND  COSTS 

Because  software  projects,  large  and  small,  tend  to  overrun  planned  schedules  and 
budgets  the  authors  felt  is  was  necessary  to  include  a  software  development  growth  factor 
to  burden  estimates  for  specific  vulnerabilities  in  Developer  Experience  and  Solution 
Requirements.  At  the  same  time,  field  experience  developing  solutions  illustrates  the 
benefits  of  learning  curve  theory  as  well;  realized  through  such  elements  as  in  increasing 
familiarity  with  the  development  application,  mastery  of  debugger  functionality,  and  code 
reuse.  This  section  of  the  report  breaks  down  the  components  of  the  growth  factor, 
explaining  how  Development  vulnerabilities  and  Learning  Curve  Theory  are  integrated  in 
the  applied  growth  factor. 

1.  Additional  Input  Variables 

a.  Developer  Characteristics 

Because  the  Developer  analyzes  the  development  work  to  be  done, 
outlines  the  work,  and  then  carries  out  the  development  work,  their  experience  is  central 
to  determining  the  potential  value  of  the  Excel  VBA  approach  for  future  work.  The 
Micro  Solution  Development  Model  considers  three  facets  of  the  Developer’s  experience; 
their  experience  using  the  Excel  application,  their  experience  in  the  Excel  VBA 
environment,  and  their  experience  in  the  functional  (task)  area  being  considered  for 
automation.  The  degree  of  experience  indicated  for  each  area  is  assigned  a  numeric 
value,  the  higher  the  better,  and  then  the  numbers  are  multiplied  together  to  arrive  at  a 
Developer  Experience  Factor  (possible  values  1  through  36).  This  Developer  Experience 
Factor  basically  determines  how  far  down  the  appropriate  learning  curve  the  model 
travels  to  arrive  at  the  growth  factor. 
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b.  Solution  Characteristics 

Solution  Characteristic  variables  are  included  in  the  model  to  focus  on  the 
work  being  considered,  capturing  two  key  elements;  the  overall  complexity  of  the 
solution  being  attempted  (based  on  proposed  functionality),  and  the  degree  to  which  the 
work  requirements  are  defined  and  understood  by  the  development  team  The  options 
available  for  input  from  the  drop-down  boxes  reflect  the  range  of  characteristics  that 
essentially  define  Micro  Solution  development.  The  input  selections  are  then  considered 
in  a  pair-wise  matrix,  as  discussed  in  the  following  paragraphs,  to  determine  which 
learning  curve  is  the  best  fit  in  determining  the  growth  factor. 

2.  Growth  Factor  Calculation 
a.  Boundary  Assumptions 

In  order  to  calculate  a  software  development  Growth  Factor  within  the 
context  of  Developer  Experience  and  Learning  Curve  Theory  it  was  necessary  to  make 
two  boundary  assumptions;  1)  maximum  or  ‘worst  case’  growth  factor,  known  in 
Learning  Curve  theory  as  the  first  unit  cost  or  Tl,  and  2)  the  range  of  learning  curve 
slopes  relevant  to  the  Micro  Solution  development  environment.  We  utilized  a  Software 
Growth  Experience  study  conducted  by  the  Navy  Center  for  Cost  Analysis  (NCCA)  as  a 
baseline  for  setting  our  boundary  assumptions7.  The  study  considered  Source  Lines  of 
Code  (SLOC)  growth  in  sixteen  program-level  DoD  weapon  system  software 
development  projects  as  shown  in  Table  1. 


7  The  Software  Development  Estimating  Handbook,  Phase  One,  “Risk  Analysis”,  NCCA,  1998. 
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DATA 

SOURCE 

MISSION 

PURPOSE 

ESTIMATED 

SLOC* 

ACTUAL 

SLOC* 

GROWTH 

FACTOR 

t? 

518.000 

TQWJQO 

1.1S 

C» 

23,599 

25,81* 

1.09 

£ 

14,000 

70.143 

5-01 

Tesdna 

41,800 

46.303 

1.11 

Software  Tools 

45.000 

45.000 

1*0 

C1 

39.294 

119.400 

3-04 

c2 

22,000 

30.000 

1.30 

SI  anal  Processinq 

15,500 

26,513 

1.71 

100,000 

122,000 

Mtsskii  Planninq 

532.000 

877.129 

1-flS 

Projects: 

C2 

206.650 

394.309 

1.01 

c2 

74.000 

82.930 

1.12 

£ 

213.800 

261.800 

1.22 

153.000 

185.000 

1.21 

c* 

83.900 

108,85® 

1J0 

1.246.272 

IMZXA 

1.02 

Table  1.  Software  Growth  Experience  Study,  NCCA,  1998 


These  projects  obviously  represent  a  range  of  work  far  outside  the  scope 
considered  in  the  MSDM;  it’s  safe  to  assume  the  projects  in  Table  1  were  far  more 
complex,  and  the  software  developers  doing  the  work  both  trained  and  experienced.  But 
the  nature  of  the  work  is  very  much  like  the  work  being  proposed  in  the  MSDM; 
translating  requirements  into  robust,  precise  instruction  sets  in  a  largely  abstract 
environment  that  rewards  both  scientific  and  creative  methodology.  So,  in  developing 
the  Growth  Factor  calculation  we  applied  two  measures  from  the  NCCA  study  in  a  broad 
sense;  the  maximum  theoretical  growth  factor  (5.01)  and  the  mean  growth  factor  (1.63). 
b.  Application  of  Learning  Curve  to  Develop  Growth  Factor 
The  Federal  Aviation  Administration  Acquisition  System  Toolset  (FAST) 
Pricing  Handbook  provides  a  good  background  on  the  fundamental  concepts  of  learning 
curve  theory,  cited  below8: 

The  Learning  Curve  was  adapted  from  the  historical  observation  that 
individuals  who  perform  repetitive  tasks  exhibit  an  improvement  in  performance  as  the 

8  Federal  Aviation  Administration  Acquisition  System  Toolset,  “Pricing  Handbook”,  Section  18.1. 
Accessed  31  Oct  2005,  available  from  http://fast.faa.gov/pricing.  Internet. 
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task  is  repeated  a  number  of  times.  Empirical  studies  of  this  phenomenon  (Wright,  T.P.; 
Asher,  H.;  and  Boston  Consulting  Group)  yield  three  conclusions  on  which  the  current 
theory  is  based: 


•  The  time  required  to  perform  a  task  decreases  as  the  task  is  repeated, 

•  The  amount  of  improvement  decreases  as  more  units  are  produced,  and 

•  The  rate  of  improvement  has  sufficient  consistency  to  allow  its  use  as  a 
prediction  tool 

Consistency  in  improvement  has  been  found  to  exist  in  the  form  of  a 
constant  percentage  reduction  in  time  required  over  successively  doubled  quantities  of 
units  produced.  The  constant  percentage  by  which  the  costs  of  doubled  quantities 
decrease  is  called  the  rate  of  learning.  The  slope  of  the  learning  curve  is  100  minus  the 
rate  of  learning.  For  example,  if  the  hours  between  doubled  quantities  are  reduced  by 
20%  (rate  of  learning) ;  it  would  be  described  as  a  curve  with  an  80%  slope. 


The  predictive  power  of  the 
learning  curve  formula  : 


y  =  axb 


b  is  the  natural 
slope  and 
represents  the 
rate  of  learning 


a  always  represents 

the  theoretical  labor  *  always  represents 
hours  required  to  build  the  number  of  the 
the  first  unit  (T1)  item  in  the  production 

sequence 


Figure  4.  Learning  Curve  Formula9 


The  formula  for  calculating  the  learning  curve  is  presented  in  Figure  4, 
and  an  example  of  an  80%  learning  curve  is  shown  in  Figure  5.  When  a  learning  rate  can 


9  Society  of  Cost  Estimating  and  Analysis,  “All  About  Learning  Curves”.  Accessed  31  Oct  2005, 
available  from  www.sceaonline.net/files.  Internet. 
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be  assumed,  predictions  can  be  made  about  the  costs  and  time  required  in  production  for 
the  nth  unit  (or  lot  of  units).  The  learning  curve  has  traditionally  been  used  to  estimate 
manufacturing  costs,  but  it  can  also  be  used  to  estimate  costs  (or  cost  factors)  of  any  other 
repetitive  process.  Specifically,  learning  curve  estimation  techniques  are  “ most  suitable 
for  estimating  the  reduction  in  cost  resulting  from  labor  and  other  efficiencies  that  come 
with  repetition  of  a  process.  The  repetitive  process  can  involve  hands-on  labor  or  mental 
exercises  and  can  range  from  simple  to  complex.”10 


$120 

w 
o 
O 
•*-> 

*e 

D 

$o  - 1 - 1 - 1 - 1 - 1 - 1 - 1 - 1 

O  2  4  6  8  10  12  14  16 

Quantity  Produced 

Figure  5.  Learning  Curve  Theory 

In  the  Micro  Solution  Development  Model  we  apply  learning  curve  theory 
to  establish  the  development  growth  factor;  an  attempt  to  account  for  the  learning  that 
takes  place  when  a  functional  with  limited  programming  background  initially  enters  the 
realm  of  Micro  application  development.  Normally,  the  likely  rate  of  learning  for  a 
particular  industry  or  project  is  based  on  historical  data.  For  example,  he  average 
learning  rate  for  the  aircraft  industry  is  85%,  though  rates  may  vary  significantly  down  in 
the  job  shops,  and  the  shipbuilding  industry  experiences  rates  between  80-85%.  But 
since  the  elements  of  Micro  Solution  development  are  somewhat  unique  we  selected  a 
range  of  probable  learning  rates  by  using  comparative  guidelines. 


10  Federal  Aviation  Administration  Acquisition  System  Toolset,  “Pricing  Handbook”,  Section  18.1 . 
Accessed  31  Oct  2005,  available  from  http://fast.faa.gov/pricing.  Internet. 
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Same  Manufacturing  operations  that  are  fully  automated  tend  to  have 
slopes  of  100%,  or  a  value  very  close  to  that  (no  learning  can  happen),  while  operations 
that  involve  a  great  deal  of  human  activity  (manual  or  cognitive)  tend  to  have  slopes  in 
the  vicinity  of  70%  (maximum  learning  can  happen).  Because  the  software  development 
process  is  highly  cognitive,  and  because  inexperienced  crews  tend  to  have  higher  learning 
rates  than  experienced  crews  in  industry  studies11,  we  selected  a  range  of  learning  rates 
from  75%  to  80%  for  calculating  the  growth  factor,  as  shown  in  Figure  6. 


To  ensure  we  were  on  the  right  track  with  our  learning  curve  assumptions, 
we  cross-checked  the  typical  Micro  Solution  development  scenario  against  the  NCCA 
analysis.  Figure  7  depicts  both  the  variable  inputs  and  calculated  Growth  Factor  in  the 
typical  Micro  Solution  scenario  (where  the  Developer-based  Experience  Factor  =18  and 
the  Solution-based  Learning  Curve  =  76%).  The  Growth  Factor  applied  by  the  MSDM 
(1.60)  is  reasonably  close  to  the  mean  observed  in  the  NCCA  study  (1.63). 


1 1  Society  of  Cost  Estimating  and  Analysis,  “All  About  Learning  Curves”.  Accessed  31  Oct  2005, 
available  from  www.sceaonline.net/files.  Internet. 
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Figure  7.  Typical  Development  Characteristics  and  Growth  Factor 

There  is  no  empirical  foundation  for  the  growth  tictor.  However,  we 
evaluated  each  possible  combination  of  characteristics  and  compared  the  resulting  factor 
for  each  scenario  to  ensure  internal  consistency.  Based  on  our  experience  the  factors 
make  sense.  The  average  developer,  as  described  in  the  report,  will  experience  50-60% 
growth  from  first  stage  planning  to  completion  of  the  project.  The  best  possible  project 
will  experience  growth  in  the  range  of  15%,  also  supported  by  our  experiences.  The 
worst  case  scenario  of  500%  growth  makes  sense  if  you  consider  the  relative 
inexperience  of  the  novice  developer,  both  in  estimating  and  performing  the  development 
work.  Certainly  this  is  an  area  where  the  learning  curve  is  steep,  made  possible  by  Excel 
application  knowledge,  code  reuse,  and  first-hand  knowledge  of  the  requirements. 
Calculation  of  the  growth  factor  is  fully  disclosed  in  Figure  8. 


Figure  8.  Mapping  Development  Characteristics  to  Growth  Factor 
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III.  MICRO  SOLUTION  DEVELOPMENT  CASE  STUDIES 


A.  FIELDED  FM  SOLUTIONS 

This  Section  of  the  report  turns  the  corner.  With  the  Micro  Solution  Development 
Model  in  place  we  now  turn  to  practical  application  of  the  model,  beginning  with  six 
fielded  FM  Micro  Solutions.  Captain  O’Hare  was  involved  directly  or  indirectly  in  the 
development  of  each  of  the  fielded  solution,  while  Captain  Krott  validated  the  savings 
factors  represented  in  the  model  and  offers  a  qualitative  ‘field  customer’  perspective. 

1.  Case#l  (GPC_RECON) 

The  Government  Purchase  Card  Reconciliation  is  a  classic  Micro  Solution;  it  was 
developed  by  FM  personnel  in  just  a  few  hours,  automates  a  routine  of  low  complexity, 
and  achieves  a  remarkable  ROI.  In  order  to  provide  a  flavor  of  the  kind  of  processes  the 
typical  Micro  Solution  addresses  we’ve  included  in  this  case  a  brief  demonstration  of  the 
functionality  of  the  GPC_RECON  solution  (Figure  9.). 


Figure  9.  Typical  Micro  Solution  Functionality  (GPC_RECON) 
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The  GPC_RECON  solution  was  developed  to  assist  the  Accounting  Liaison 
Office  (ALO)  with  reconciliation  of  Government  funding  and  actual  expenditures  as  they 
relate  to  the  Government  Purchase  Card  program.  In  the  upper  left  hand  comer  of  Figure 
9  is  data  set  from  the  US  Bank  website,  reporting  current  actual  expenditures  for  each 
card.  In  the  lower  left  is  shown  the  funding  applied  to  each  card,  records  that  must  be 
pulled  from  the  Air  Force  General  Accounting  and  Finance  System  (GAFS).  The  upper 
right  depicts  the  GPC_RECON  tool  workbook.  The  user  of  the  tool  loads  the  current 
data  into  the  corresponding  worksheets  and  then  clicks  the  Recon  button  (circled).  In 
seconds  the  tool  reconciles  the  two  data  sets  matching  funding  with  expenses  for  each 
account  (card),  then  drops  the  data  into  the  output  worksheet  where  it  is  sorted  and 
filtered  to  display  only  the  overextended  accounts.  Hundreds  of  accounts  are  reduced 
down  to  the  few  that  warrant  attention. 

Now  we’ll  use  the  Micro  Solution  Development  Model  to  evaluate  the  solution  in 
retrospect.  The  actual  development  scenario  for  GPC_RECON,  using  an  organizational 
benefit  perspective,  is  represented  in  Figure  10.  Reviewing  the  inputs  to  the  model  we 
find;  the  task  under  the  previous  method  took  two  hours  (cutting  and  pasting  data  to 
properly  match  the  300  accounts)  and  was  required  twice  weekly,  the  task  was  performed 
by  only  one  person  in  the  ALO  office,  and  the  development  time  was  only  four  hours 
with  90  minutes  allotted  for  requirements  development  and  testing.  The  Development 
Characteristics  are  shown  for  informational  purposes,  since  no  growth  factor  is  applied 
(“Past  Actual”). 

The  model  gives  the  GPC_RECON  high  marks,  with  a  ROI  of  1,744%  and 
Payback  Period  of  only  twenty  days.  From  a  qualitative  aspect,  the  speed  and  accuracy 
provided  by  the  solution  enables  the  analyst  to  more  effectively  manage  the  Government 
Purchase  Card  program  (several  hundred  accounts  at  an  operational  Wing).  As  opposed 
to  spending  hour’s  simply  moving  data  around  in  an  effort  to  get  meaningful  information, 
the  analyst  can  take  immediate  action  on  meaningful  information.  In  the  GPC  program 
this  means  stronger  management  controls,  more  likely  detection  of  fraudulent  charges, 
and  better  expenditure  management  since  there  is  now  time  to  analyze  account  activity  on 
a  daily  basis.  These  qualitative  benefits  are  not  addressed  in  the  model’s  output. 
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GPC  RECON 


INPUTS 


(Development  Cost  Factors 
(Functional  Labor  Rate  (hourly) 
Developer  Labor  Rate  (hourly) 
Basis  for  Requirements 
Functional  Time  Required  (hours) 
(Developer  Time  Required  (hours) 
|User  Training  Required  (hrs/user) 


Past  Actual 


$39.35 

S43.55 


(Development  Savings  Factors 

Current  Task  Time  (minutes) 

120.01 

Current  Task  Frequency  (per  week) 

2 

Number  of  Users  Tasked 

l] 

|User  Labor  Rate  (hourly) _ E-3 _ 

_ $21.14| 

(Development  Characteristics 
|  Developer  VBA  Experience 
Developer  Excel  Application  Experience 
Developer  Functional  Experience 
Solution  Type 
|  Solution  Requirements 


Growth  Factor  »> 


OUTPUTS 

Return  on  Investment  (in  one  year) 

1.744% 

Payback  Period  (days) 

20 

Savings/Use 

$42.28 

Annual  Savings 

$4,158 

Figure  10.  GPC_RECON  (Organizational  Benefit) 


As  we’ll  see  throughout  these  cases,  the  assumptions  made  to  arrive  at  an  input 
for  Number  of  Users  Tasked  drives  the  output.  In  Figure  10  the  model  is  presented  under 
the  assumption  the  solution  benefits  only  the  organization  that  developed  it.  In  practice 
many  Micro  Solutions,  including  GPC_RECON  and  the  others  presented  in  this  section, 
could  and  have  been  used  in  many  organizations  within  the  Air  Force  FM  community 
since  our  legacy  systems,  tracking,  and  reporting  requirements  are  largely  standardized 
from  one  operation  to  the  next.  In  Figure  1 1  the  model  is  presented  under  the  assumption 
that  the  model  is  available  and  put  into  use  across  the  FM  community. 
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GPC  RECON 


INPUTS 


(Development  Cost  Factors 
Functional  Labor  Rate  (hourly) 
Developer  Labor  Rate  (hourly) 
Basis  for  Requirements 
Functional  Time  Required  (hours) 
Developer  Time  Required  (hours) 
|User  Training  Required  (hrs/user) 


Past  Actual 


$39.35| 

$43.55 


Development  Savings  Factors 

Current  Task  Time  (minutes) 

120.0 

Current  Task  Frequency  (per  week) 

21 

Number  of  Users  Tasked 

56 

User  Labor  Rate  (hourly)  E-3 

_ $21.14| 

Development  Characteristics 
Developer  VBA  Experience 
Developer  Excel  Application  Experience 
Developer  Functional  Experience 
Solution  Type 
Solution  Requirements 


Growth  Factor  »> 


Return  on  Investment  (in  one  year) 

103.140% 

Payback  Period  (days) 

0 

Savings/Use 

$42.28 

Annual  Savings 

$245,993 

Figure  1 1.  GPC_RECON  (Community  Benefit) 


The  FM  Community,  for  all  of  our  MSDM  calculations,  is  defined  as  the  74 
Major  Air  Force  installations12,  with  an  assumed  community  penetration  of  75%,  for  a 
total  of  56  Wing  organizations.  The  community  assumption  also  suggests  the  Task  Time 
Required  entry  is  a  typical  task  time  required  at  a  typical  Wing  (though  in  fact  the 
number  of  records  and  situational  factors  throughout  the  year  may  vary  greatly).  Note 
the  dramatic  increase  in  benefit  potential  when  available  and  supported  in  the 
community;  this  solution  has  the  potential  to  save  11,636  hours  annually,  or  $245,993. 
The  next  two  solutions  are  presented  under  the  Community  Benefits  assumption  as  well, 
since  they  too  have  a  foothold  in  common  system  outputs  and  procedures. 

12  Airman  Magazine,  January  2005. 
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2.  Case#2  (TRAVEL_MERGE) 

The  TRAVEL_MERGE  solution  was  developed  by  a  novice  FM  Developer  to 
assist  the  Accounting  Liaison  Office  (ALO)  with  management  of  the  Open  Travel  Order 
Listing  (GOO),  which  lists  all  current  open  travel  documents  in  the  Wing  organization. 
The  GOO  is  a  standard  tool  for  managing  the  Wing  travel  program  but  unfortunately  does 
not  include  the  name  or  organization  for  the  reported  open  travel  documents. 
TRAVEL_MERGE  integrates  the  GOO  listing  with  a  current  DP  listing  then  looks  up  the 
respective  name  and  organization  for  each  document  based  on  the  Social  Security 
Number.  The  model  evaluation  of  the  TRAVEL_MERGE  solution  is  shown  in  Figure 
12,  using  the  community  benefits  approach.  Again,  substantial  leverage  is  achieved  under 
the  community  benefit  assumption,  freeing  4,805  hours  annually  at  a  savings  of 
$120,593. 


TRAVEL  MERGE 


INPUTS 


Development  Cost  Factors 
Functional  Labor  Rate  (hourly) 
Developer  Labor  Rate  (hourly) 
Basis  for  Requirements 
I  Functional  Time  Required  < hours) 
{Developer  Time  Required  (hours) 
[User  Training  Required  (hrs/user) 


$39  35 
$36.74 


Past  Actual 


(Development  Savings  Factors 

Current  Task  Time  (minutes) 

loo.ol 

Current  Task  Frequency  (per  week) 

ll 

Number  of  Users  Tasked 

_ 56] 

|User  Labor  Rate  (hourly) _ 

E-4 _ 

_ $25-10| 

I  Development  Characteristics 
I  Developer  VBA  Experience 
Developer  Excel  Application  Experience 
Developer  Functional  Experience 
I  Solution  Type 
I  Solution  Requirements 


Growth  Factor  »> 


OUTPUTS 

Return  on  Investment  (in  one  year) 

9.993% 

Payback  Period  (days) 

4 

Savings/Use 

$41.83 

Annual  Savings 

SI  20.593 

Figure  12.  TRAVEL_MERGE  (Community  Benefit) 


29 


From  a  qualitative  aspect  the  capabilities  of  this  solution  enable  the  Accounting 
Liaison  Office  to  more  effectively  manage  open  travel  orders.  Under  the  pre-solution 
process  the  GOO  listing,  often  several  hundred  documents  (travel  orders),  must  be  bumped 
against  the  DP  listing  manually.  This  process  is  time-consuming  enough  to  push  it 
outside  the  scope  of  on  going  day-to-day  management  and  analysis  in  many 
organizations.  The  TRAVEL_MERGE  solution  places  the  listing  under  a  consistent, 
methodical  management  control  process  and  enables  the  ALO  to  keep  the  listing  clear 
instead  of  scrubbing  month’s  worth  of  documents  at  the  end  of  an  accounting  period. 
Simply  put,  this  solution  inspires  proactive  management. 

3.  CASE#3  (ODL_TRAC) 

The  ODL_TRAC  solution  was  developed  by  an  experienced  FM  Developer  to 
assist  Resource  Advisors  and  Budget  Analysts  across  the  FM  community  with  the  task  of 
managing  open  obligation  documents.  It  was  designed  to  be  a  community  solution  from 
inception.  The  solution  works  off  inputs  from  one  of  two  AF  reporting  programs, 
reconciling  the  current  Open  Document  Listing  file  (a  snapshot  in  time  of  outstanding 
obligation  document  records)  with  a  previous  file  and  returning  in  a  single  worksheet 
view  a  synopsis  of  the  changes  that  has  taken  place.  The  solution  offers  a  status  for  each 
document  (NEW,  DROP,  CHANGED,  or  UNCHANGED)  along  with  a  summary  of  the 
relevant  financial  activity  for  each  document.  The  same  file  can  be  used  repeatedly, 
allowing  the  analyst  to  keep  a  record  or  remarks  for  each  document. 

Most  Resource  Advisors  are  charged  with  managing  dozens,  or  hundreds,  of  open 
obligation  documents  simultaneously.  This  is  normally  accomplished  manually,  either  by 
printing  out  listings  for  side-by-side  comparison,  or  by  dropping  the  report  files  into 
Excel  so  the  analyst  can  sort  records  and  make  notes  to  aid  in  tracking  activity.  Each 
week  the  process  is  repeated,  and  analysts  often  resort  to  copying  and  pasting  notes  after 
reconciling  the  two  listings.  OR,  due  to  the  time  required  to  manage  the  documents  the 
resource  analyst  resorts  to  management  by  exception,  working  documents  after  problems 
arise  or  in  a  last  ditch  effort  to  free  obligation  authority  (“scrubbing  the  books”). 
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ODL  TRAC 


INPUTS 


[Development  Cost  Factors 
1  Functional  Labor  Rate  (hourly) 
Developer  Labor  Rate  (hourly) 
Basis  for  Requirements 
Functional  Time  Required  (hours) 
Developer  Time  Required  (hours) 
|User  Training  Required  (hrs/user) 


Past  Actual 


$47.63 

$43.55 

20.0 

120.0 

0.5l 


(Development  Savings  Factors 

Current  Task  Time  (minutes) 

60.0 

Current  Task  Frequency  (per  week) 

1 

Number  of  Users  Tasked 

336 

|User  Labor  Rate  (hourly)  GS-9 

$32.84 

■  Development  Characteristics 
I  Developer  VBA  Experience 
Developer  Excel  Application  Experience 
Developer  Functional  Experience 
I  Solution  Type 
I  Solution  Requirements 


Growth  Factor  »> 


OUTPUTS 

Return  on  Investment  (in  one  year) 

9.164% 

Payback  Period  (days) 

4 

Savings/Use 

$32.84 

Annual  Savings 

$567,670 

Figure  13.  ODL_TRAC  (Community  Benefit) 


From  a  qualitative  perspective  ODL_TRAC  provides  a  document  management 
tool  that  encourages  effective  tracking  of  document  activity.  This  means  more  time  can 
be  devoted  to  analyzing  the  program  and  resolving  problems,  providing  for  a  more 
accurate  view  of  actual  obligations  incurred  on  a  routine  basis.  This  solution  was  a  great 
deal  more  complex,  consuming  considerable  resource  in  development.  Current  Task 
Time  is  based  on  a  typical  reconciliation  process  in  a  typical  Group-Level  organization. 
The  Number  of  Users  Tasked  is  based  on  the  number  of  Group  Resource  Advisors  in  a 
typical  Wing  (Operations  Group,  Maintenance  Group,  Mission  Support  Group,  Wing 
Staff,  Medical  Group,  and  the  ALO)  times  the  number  of  Wings  considered  in  our 
Community  penetration  assumption  (75%  of  Active  Duty  Wings),  or  6  X  56  =  336.  This 
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is  a  conservative  estimate,  since  it  does  not  include  others  who  might  benefit  from  the 
solution;  Guard  and  Reserve  units.  Headquarters  personnel,  and  Resource  Advisors  and 
analysts  below  the  Group  level. 

From  the  quantitative  perspective  the  MSDM  evaluation  of  ODL_TRAC,  under 
the  assumptions  discussed,  is  truly  remarkable.  As  shown  in  Figure  13,  the  ODL_TRAC 
solution  posts  a  ROI  of  9,164%,  and  has  the  potential  to  save  $567,670  annually,  freeing 
17,286  labor  hours  annually.  This  Micro  Solution,  developed  and  fielded  in  February 
2003,  is  still  relevant  and  used  today  across  the  Air  Force. 

4.  CASE#4  (COPTRS) 

The  COPTRS  solution  was  developed  by  a  novice  FM  Developer  as  a  stop-gap 
measure  to  correct  an  Initial  Operating  Capability  (IOC)  deficiency  in  the  Accounts 
Receivable  module  of  a  newly  fielded  system.  Specifically,  the  Accounts  Receivable 
module  had  a  faulty  design,  billing  reimbursable  work  orders  based  on  estimated 
resources  instead  of  actual  resources.  Three  months  into  the  IOC  Fiscal  Year  the 
responsible  organization  had  billed  only  $3M  in  a  program  that  averaged  $100M 
annually.  The  Comptroller  summoned  auditors  from  the  Headquarters  agency  and  a 
functional  team  was  assembled  to  correct  the  deficiency. 

The  COPTRS  solution  was  developed  in  response  to  this  crisis.  Once  the 
functional  team  had  agreed  on  a  solution  a  means  of  translating  actual  resources  against 
the  appropriate  cost  rates  (more  than  50  rates  and  six  customer  types)  for  each  project  for 
each  month  was  sought.  In  addition,  billings  already  released  had  to  be  evaluated  and 
business  rules  applied  to  determine  corrective  action,  if  any,  to  apply.  COPTRS  allowed 
the  billing  analyst  to  import  an  actual  resources  data  file,  translating  the  cost  rates  into  a 
customer-specific  price,  and  providing  an  electronic  file  output  for  use  downstream  in  the 
Accounts  receivable  module.  The  development  work  and  testing  took  place  over  a  four 
month  period  and  was  intensive.  Once  fielded  this  organization/situation-specific 
solution  was  utilized  to  reconcile,  calculate,  certify,  and  post  more  than  $102M  in 
receivables. 


32 


COPTRS 


INPUTS 


(Development  Cost  Factors 
(Functional  Labor  Rate  (hourly) 
Developer  Labor  Rate  (hourly) 
Basis  for  Requirements 
Functional  Time  Required  (hours) 
(Developer  Time  Required  (hours) 
|User  Training  Required  (hrs/user) 


Grade 

GS-11 

0-1 


Past  Actual 


$39.74 

$36.74 

90.0 

240.0 

0.5l 


(Development  Savings  Factors 

Current  Task  Time  (minutes) 

1 15.0 

Current  Task  Frequency  (per  week) 

24  2[ 

Number  of  Users  Tasked 

ll 

(User  Labor  Rate  (hourty) _ GS-1 1 _ 

_ $39.74| 

(Development  Characteristics 
|  Developer  VBA  Experience 
Developer  Excel  Application  Experience 
Developer  Functional  Experience 
Solution  Type 
|  Solution  Requirements 


Growth  Factor  »> 


OUTPUTS 

Return  on  Investment  (in  one  year) 

673% 

Payback  Period  (days) 

47 

Savings/Use 

$76.18 

Annual  Savings 

$83,568 

Figure  14.  COPTRS  (Organizational  Benefit) 


The  task  was  defined  in  this  scenario  as  the  processing  of  one  project  invoice  for  a 
single  month.  Current  task  time  was  the  time  that  would  have  been  required  to  prepare 
an  auditable  invoice  under  the  best  of  circumstances  without  automation.  The  current 
task  frequency  represents  the  average  number  of  invoices  that  had  to  be  run  in  a  single 
week  (approximately  105  projects  monthly).  This  solution  demonstrates  the  agility, 
flexibility,  and  range  of  capabilities  available  in  the  Excel  VBA  environment.  Though 
the  ROI,  Payback,  and  Annual  Savings  are  not  as  remarkable  as  the  previous  cases,  this 
solution  clearly  pays  for  itself  (Figure  14).  The  qualitative  aspects  provided  were  the 
driving  factor  behind  this  solution;  billing  records  were  restored,  processes  for  dealing 
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with  discrepancies  were  standardized  to  the  satisfaction  of  the  independent  auditors,  and 
time  was  provided  for  a  systematic  solution  to  be  developed. 

5.  CASE#5  (SBSS  JNTERF  AGE) 

The  SBSS_INTERFACE  solution  was  developed  by  an  experienced  FM 
Developer  to  automate  the  steps  required  in  processing  raw  invoice  (expense)  data  from 
the  SBSS  into  the  Accounts  Payable  module  of  a  newly  implemented  COTS  Financial 
Management  System  This  solution  served  as  a  smart  interface,  since  the  COTS  product 
had  no  front-end  edits  and  no  interface  was  funded  in  the  original  implementation.  The 
alternative  to  automating  this  routine  was  to  manually  convert  hundreds  of  SBSS  records 
weekly  from  the  D04  listing  format  into  an  approved  cost  accounting  framework  based 
on  the  United  States  Standard  General  Fedger  (USSGF).  Once  records  were  converted, 
the  work  order  number  had  to  be  validated  (cross-referenced),  and  then  the  invoice  was 
ready  to  hand-type  into  the  COTS  28-field  Accounts  Payable  Entry  Fog.  This  procedure 
involved  nearly  one  Full  Time  Equivalent,  and  was  considered  a  material  weakness. 
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SBSS  INTERFACE 


INPUTS 


Figure  15.  SBSS_INTERFACE  (Organizational  Benefit) 


The  SBSS_INTERFACE  solution  provided  an  electronic,  secure  means  to  quickly 
convert  legacy  data,  according  to  a  standard  set  of  business  rules.  The  ‘spreadsheet’ 
approach  to  the  interface  also  provided  a  step  for  the  analyst  to  review  data  by  exception 
before  entry  processing,  including  an  automated  query  against  the  production  system  to 
validate  work  order  numbers.  Finally,  output  files  were  created  to  facilitate  electronic 
loading  of  invoice  records  into  the  COTS  AP  module.  Like  the  previous  case,  the 
SBSS_INTERFACE  solution  benefited  a  single  process  in  a  single  organization.  And, 
like  the  previous  case,  the  qualitative  benefits  were  considered  to  be  of  far  greater 
importance  to  the  management  team  than  development  cost  considerations.  Still,  Figure 
15  makes  it  clear  this  project  was  profitable;  development  costs  were  recovered  in  less 
than  six  months  and  370  labor  hours  were  freed  annually.  This  solution  is  still  in  use 
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three  years  after  development;  it  serves  as  an  offset  to  the  cost  of  formally  developing  an 
interface,  while  meeting  audit  requirements. 

6.  CA  S  W6  (LABOR_RECON) 

The  LABOR_RECON  solution  was  developed  by  a  novice  FM  Developer  to 
facilitate  the  reconciliation  of  pay  records  between  the  organization’s  cost  accounting 
system  and  the  Defense  Civilian  Payroll  System  (DCPS).  Besides  compressing  the  task 
time  for  reconciliation,  this  project  served  as  a  “teeth-cutting”  exercise  for  the  novice 
Developer.  Normally  the  data  in  DCPS  is  more  reliable,  but  any  discrepancies  between 
the  two  systems  (i.e.  Pay  Grade/Step,  Work  Center)  could  cause  errors  in  Work  Center 
cost  rates.  The  old  method  of  reconciling  these  two  systems  was  to  simply  print  reports 
from  each  and  manually  work  through  the  records  to  sort  discrepancies.  This  task  was  so 
cumbersome  that  often  the  discrepancies  were  worked  on  an  exception  basis,  once  a 
problem  became  apparent.  By  pivoting  on  the  Social  Security  Number  the 
LABOR_RECON  solution  was  able  to  reconcile  the  two  payroll  files  in  seconds, 
grouping  potential  discrepancies  by  type  and  providing  a  summary  report  that  was 
immediately  actionable.  However,  as  shown  in  Figure  16,  this  solution  did  not  pay  for 
itself  in  a  quantitative  sense;  achieving  a  -  9%  ROI  and  Payback  Period  of  more  than  365 
days.  An  objective  analysis  of  this  project  might  lead  us  to  invest  development  resources 
elsewhere. 
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LABOR  RECON 


INPUTS 


OUTPUTS 


OUTPUTS 


Return  on  Investment  (in  one  year)  -9% 

Payback  Period  (days)  399 

Savings/Use  S67.14 

Annual  Savings  ($163) 


Figure  16.  LABOR_RECON  (Organizational  Benefit) 

B.  UNFIELDED  FM  SOLUTIONS 

This  Section  of  the  report  addresses  potential  FM  Micro  Solution  projects; 
projects  that  have  a  requirements  basis  and  are  typical  of  other  opportunities  existing 
today  in  FM  operations.  These  cases  will  call  upon  the  predictive  capabilities  of  our 
model  and  in  so  doing  will  burden  the  initial  work  estimates  with  a  growth  factor  to 
provide  a  conservative,  perhaps  more  realistic,  appraisal  of  the  solution  value  potential. 


1.  CASE#7  (CIVPAY_TRANS) 

The  CIVPAY_TRANS  case  is  a  Micro  Solution  candidate  whose  aim  is  to 
provide  Civilian  Payroll  Analysts  across  the  Air  Force  with  a  more  effective  means  for 
managing  their  Wing-level  programs.  Today  Wing-level  data  files  from  DCPS, 
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representing  thousands  of  employees  in  dozens  of  Work  Centers,  are  only  available  in  the 
original  paper -report  based  format;  the  same  used  to  print  on  128-column  multi-page 
listings  that  once  filled  listing  cabinets  in  Comptroller  offices  across  the  globe.  The  data 
cannot  be  opened  in  a  spreadsheet  format  using  the  Excel  Text  Import  Wizard.  To  get  at 
this  data  the  FM  Developer  will  have  to  use  other  Excel  VBA  capabilities  to  exploit  rule 
set-based  patterns  and  so  untangle  the  data  for  presentation  in  a  spreadsheet  format. 
Then,  once  the  data  is  formatted  in  a  usable  format,  there  are  some  standard  management 
information  requirements  that  could  be  satisfied  in  an  Excel  VBA  driven  first-order 
analysis  of  the  data.  The  result  would  be  an  actionable  management  report  that  would 
largely  compress  the  time  required  to  perform  a  pay -period  Civilian  Payroll  analysis. 


erVPAY  TRANS 


INPUTS 


Jevelopment  Cost  Factors 
I  Functional  Labor  Rate  (hourly) 
Developer  Labor  Rate  (hourly) 
Basis  for  Requirements 
Functional  Time  Required  (hours) 
Developer  Time  Required  (hours) 
|User  Training  Required  (hrs/user) 


Grade 

GS-12 

0-3 


$47.63 

$55.32 


Future  Estimate 


(Development  Savings  Factors 

Current  Task  Time  (minutes) 

180.0 

Current  Task  Frequency  (per  week) 

0.5 

Number  of  Users  Tasked 

_ sel 

|User  Labor  Rate  (hourly) _ GS-7 _ 

_ S26.85| 

Development  Characteristics 
Developer  VBA  Experience 
Developer  Excel  Application  Experience 
Developer  Functional  Experience 
Solution  Type 
Solution  Requirements 


Growth  Factor  »> 


Projects  >=  3 
Advanced 
Functional 
Three  or  more 
Understood  and  Defined 
1.7001 


OUTPUTS 

Return  on  Investment  (in  one  year) 

1,963% 

Payback  Period  (days) 

18 

Savings/Use 

$80.56 

Annual  Savings 

$111,615 

Figure  17.  CIVPAY_TRANS  (Community  Benefit) 
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The  CIVPAY_TRANS  case  development  potential  is  shown  in  Figure  17,  based 
on  Development  Savings  Factors  provided  by  a  Wing-level  Budget  Officer13.  The 
Number  of  Users  assumes  the  Civilian  Payroll  programs  are  managed  exclusively  at  the 
Wing-level;  one  times  the  number  of  Wings  considered  in  our  Community  penetration 
assumption  (75%  of  Active  Duty  Wings),  or  1  X  56  =  56.  The  Development  Cost 
Factors  were  provided  by  an  Experienced  FM  Excel  VBA  Developer  after  a  thorough 
review  of  the  requirements.  The  resulting  development  potential  is  outstanding,  and  the 
indicated  Annual  Savings  corresponds  closely  with  the  Community  Benefit  cases 
previously  discussed.  Once  fielded,  this  solution  has  the  potential  to  recoup 
Development  Costs  in  the  first  month,  while  providing  substantial  qualitative  benefits  as 
well. 


2.  CASE#8  (D J  MPS_REJECTS ) 

The  DJMPS_REJECTS  case  is  a  Micro  Solution  candidate  that  is  aimed  at 
compressing  the  task  time  required  to  pull  and  analyze  the  Defense  Joint  Military  Pay 
System  (DJMPS)  transaction  reject  listing.  This  is  a  classic  example  of  a  straight¬ 
forward  task  that  is  dependent  on  an  outmoded  data  source,  in  this  case  the  DJMPS  data 
which  can  only  be  retrieved  in  a  *.dat  file  format  and  mist  be  imported  and  reformatted 
prior  to  use.  Though  the  daily  process  of  churning  the  data  takes  only  a  few  minutes  (10 
minutes),  the  community  assumptions  makes  this  a  strong  candidate  for  automation.  The 
DJMPS_REJECTS  case  development  potential  is  shown  in  Figure  18,  based  on 
Development  Savings  Factors  provided  by  an  experienced  Financial  Services  Officer14. 
The  Number  of  Users  assumes  the  program  is  centrally  managed  at  the  Wing  level;  one 
times  the  number  of  Wings  considered  in  our  Community  penetration  assumption  (75% 
of  Active  Duty  Wings),  or  1  X  56  =  56.  The  Development  Cost  Factors  were  provided 
by  an  Experienced  FM  Excel  VBA  Developer,  and  include  consideration  for  limited 
enhancements  such  as  sorting,  grouping,  and  conditional  formatting  options. 


13  Interview,  24  August  2005.  Suzanne  Colpitts,  GS-12,  62  CPTS/FMA. 

14  Interview,  07  November  2005.  MSgt  Ian  Martinez,  311th  DLI/FSO. 
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DJMPS  REJECTS 


INPUTS 


)evelopment  Cost  Factors 
[Functional  Labor  Rate  (hourly) 
Developer  Labor  Rate  (hourly) 
Basis  for  Requirements 
Functional  Time  Required  (hours) 
Developer  Time  Required  (hours) 
|User  Training  Required  (hrs/user) 


$39.35 

$55.32 


Future  Estimate 


[Development  Savings  Factors 

Current  Task  Time  (minutes) 

10.0 

Current  Task  Frequency  (per  week) 

5.0 

Number  of  Users  Tasked 

56 

|User  Labor  Rate  (hourly)  E-4 

$25.10| 

[Development  Characteristics 
Developer  VBA  Experience 
Developer  Excel  Application  Experience 
Developer  Functional  Experience 
Solution  Type 
Solution  Requirements 


Growth  Factor  >» 


Projects  >=  3 
Advanced 
Functional 
Any  Two 
Understood 
1.6036 


OUTPUTS 

Return  on  Investment  (in  one  year) 

15,034% 

Payback  Period  (days) 

2 

Savings/Use 

$4.18 

Annual  Savings 

S60.498 

Figure  18.  DJMPS_REJECTS  (Community  Benefit) 


Though  the  MSDM  quantitative  output  represented  is  notable,  with  a  Payback 
Period  of  less  than  three  days,  the  qualitative  potential  of  this  automation  candidate  are 
more  important.  Daily  management  of  the  REJECT  listing  is  required  at  Wing-level  to 
ensure  pay  records  are  accurate.  The  morale  impact  of  inaccurate  pay  records  is  hard  to 
value,  but  is  at  the  heart  of  Air  Force  readiness.  Recent  problems  with  related  personnel 
system  implementations  have  brought  the  importance  of  proactive  daily  management  in 
this  area  into  focus;  Wings  that  are  striving  to  manage  the  exception  transactions  in 
DJMPS  find  it  a  challenging  task  to  keep  the  listing  clear,  Wing  organizations  with  no 
daily  management  approach  are  simply  reacting  to  pay  problems  as  they  become 
apparent. 
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C.  ANALYSIS 

Because  the  development  projects  analyzed  in  this  section  represent  such  a  wide 
range  of  complexity,  orientation,  and  value,  we  decided  it  would  be  helpful  to  attempt  a 
segmentation  of  the  solution  cases .  We  wanted  to  capture  a  qualitative  perspective,  as 
well  as  the  modeled  quantitative  value,  so  we  assigned  a  relative  value  of  qualitative 
benefit.  Selection  of  the  measure  of  qualitative  value  was  based  on  the  degree  to  which 
the  solution  did,  or  would,  contribute  directly  to  the  operational  and  strategic  goals  of 
the  organization  or  community.  Once  qualitative  measures  were  assigned,  the  solutions 
were  mapped  into  the  segmentation  matrix  as  shown  in  Figure  19.  Note  the  ‘blue’  data 
points  represent  un-fielded  solutions. 


Figure  19.  Micro  Solution  Segmentation  Analysis 


The  data  points  are  segmented  into  the  four  quadrants  as  shown  (A-D).  Basically, 
the  solutions  that  mapped  into  Quadrant  A  have  questionable  development  value,  while 
the  solutions  in  Quadrant  C  have  outstanding  overall  development  value.  Many  potential 
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solutions  will  fall  into  Quadrants  B  and  C,  where  they  have  the  potential  to  make 
important  contributions.  General  characterizations  of  each  segment  follow: 

Quadrant  A  (Task  Orientation-Organization  Benefit):  The  only  solution  that  fell 
into  this  quadrant  was  LABOR_RECON,  which  was  taken  on  primarily  as  a  training 
project.  The  solution  still  provided  some  benefits  once  completed,  but  those  benefits  are 
limited  to  a  single  duty  position.  In  light  of  the  alternatives,  focusing  development  efforts 
on  such  a  project  is  unwise.  It  should  be  noted  that  developers  are  often  focused  on 
solving  organization-specific  problems. 

Quadrant  B  (Tactical  Orientation-Organization  Benefit):  These  solutions  are 
organization  specific,  but  differ  from  Quadrant  A  in  that  they  are  considered  essential 
from  a  qualitative  perspective.  In  the  case  COPTRS  and  SBSS_INTERFACE,  the 
organizations  were  unconcerned  with  the  Development  Costs  of  solutions  that  were 
moderately  complex.  These  solutions  demonstrate  the  flexibility,  power,  and  agile  nature 
of  Excel  VBA  development  work. 

Quadrant  C  (Tactical  Orientation-Community  Benefit):  These  solutions  are  the 
‘best  of  the  best’,  providing  solid  returns  on  both  the  qualitative  and  quantitative  fronts. 
These  are  the  solution  development  candidates  with  the  greatest  potential  to  streamline 
operations,  yet  no  one  in  the  FM  community  has  responsibility  for  development  or 
support  of  these  solutions.  As  such,  implementation  of  even  the  best  practices  and  field 
solutions  are  not  consistently  applied  in  the  community. 

Quadrant  D  (Task  Orientation- Community  Benefit):  Solutions  in  this  quadrant 
have  very  short  development  cycles,  and  are  focused  on  task  compression  techniques  that 
would  benefit  front-line  workers  across  a  community.  Typically  these  solutions  will 
evolve  into  tools  that  provide  a  degree  of  automated  analytical  capability.  Like  the 
Quadrant  C  solutions,  there  is  no  one  in  the  community  responsible  for  supporting 
‘standard’  Micro  Solutions  of  this  nature. 
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D.  CONCLUSIONS 


Great  ROI,  Savings  Potential.  Even  with  the  one  year  time  horizon  assumption, 
the  Micro  Solution  Development  Model  clearly  demonstrates  a  lucrative  investment 
potential.  The  average  Return  on  Investment  values  for  the  cases  modeled,  disregarding 
the  highest  and  lowest  values,  is  6,162%  in  the  first  year!  The  community  benefit 
solutions  should  be  targeted;  the  five  community  benefit  solution  cases  had  an  average 
Payback  Period  of  only  5.6  days,  and  a  cumulative  annual  savings  of  $1,107,000. 

Supports  Key  Business  Area  Transformation  Initiatives.  The  Micro  Solution 
development  approach  is  transformation  in  action.  Based  on  the  concept  of  leveraging 
labor  resources  and  software  already  available  on  the  desktop,  Micro  Solutions  are  the 
kind  of  innovations  envisioned  in  the  Air  Force  Transformation  Flight  Plan,  enabling; 
“ increased  efficiencies  through  better,  simplified,  integrated  processes  and  better  support 
tools”,  “ compression  of  average  process  cycle  times  by  a  factor  of  four”,  and  “the 
empowerment  of  personnel  and  enrichment  of  job  functions  ”15. 

Micro  Solution  Development  is  Within  the  Reach  of  FM  Professionals.  The 

case  studies  demonstrate  the  ingenuity  of  FM  professionals  in  the  field,  and  the  potential 
to  reap  big  savings  from  ‘small’  ideas  and  ‘small’,  desktop-based  solutions.  Excel  VBA 
training  is  the  logical  next  step  for  our  FM  personnel.  The  agility  and  flexibility  offered 
by  Excel  VBA,  to  solve  pressing  problems  or  provide  seamless  interfaces,  must  be  grown 
ahead  of  time  if  we  are  to  meet  the  challenge  of  fielding  new  systems  in  an  uncertain 
environment. 

Field  Leadership  Awareness.  Though  the  Excel  application  is  used  extensively 
in  every  field  of  business  operations,  the  capabilities  and  extraordinary  usefulness  of 
Excel  VBA  seems  poorly  understood  at  the  field  leadership  level.  Field  leaders  should  be 
aware  of  the  precise,  practical  functionality  and  ROI  potential  offered  by  Excel  VBA, 


'5  USAF  Transformation  Flight  Plan  6  Jan  2005.  Accessed  31  Oct  2005,  available  from 
http://www.oft.osd.mil/library/libraryfiles/document_385_2004_USAF_Transformation_Flight_Plan.pdf. 
Internet . 
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especially  leaders  in  the  DoD  business  community.  This  is  an  emerging  field  and  should 
be  addressed  in  DoD  educational  programs  if  we  are  to  thrive  in  an  environment  of 
continuing  personnel  reductions. 

Not  real  money.  The  annual  savings  presented  in  the  Micro  Solution 
Development  Model  for  each  case  do  not,  as  previously  noted,  equate  to  an  actual 
reduction  in  cash  disbursements  (unless  personnel  reductions  accompany  fielding  of  a 
particular  solution).  Instead,  the  annual  savings  represent  the  value  of  the  labor  hours 
saved.  The  MSDM  does  not  make  a  case  for  reducing  the  number  of  workers,  but  rather 
suggests  the  degree  of  waste  associated  with  non-value  added  tasks.  Unfortunately,  it’s 
difficult  to  get  support  for  DoD  investments  where  the  benefits  don’t  translate  directly 
into  funding  or  personnel  reductions. 

Community  Penetration  is  Far  Below  Potential.  The  outstanding  ROI  and 
annual  savings  potential  offered  by  the  community  solution  cases  presented  obviously 
depend  on  penetration.  The  SAF/FM  Automated  Tools  Forum  (ATF),  hosted  on  the  FM 
Knowledge  Now  website,  provides  a  place  for  users  to  upload,  download,  and  comment 
on  community  solutions,  but  community  penetration  is  still  far  below  potential.  The 
authors  believe  the  primary  reason  for  poor  community  penetration  of  fielded  solutions  is 
a  lack  of  marketing  and  support. 
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IV.  RECOMMENDATIONS 


A.  FM  MICRO  SOLUTION  DEVELOPMENT  AND  SUPPORT  TEAM 

Based  on  the  conclusions  presented  in  this  report,  the  authors  recommend 
establishing  an  FM  Micro  .Solution  Development  and  Support  Team.  This  Team  would 
be  focused  on  leveraging  Micro  Solutions  from  an  FM  Community  perspective.  The 
team  would  formalize,  in  a  sense,  the  innovative  capacity  of  the  MSDM  approach  and  the 
most  relevant  solutions  available.  Specific  functions  placed  under  the  responsibility  of 
this  team  would  include: 

•  Marketing.  Establishing  a  presence  at  functional,  command,  and 
community  conferences  to  ‘sell’  the  best  practice  solutions  already 
available  on  the  Automated  Tools  Forum,  shown  in  Figure  20.  Providing 
short  demonstration-centered  workshops  at  conferences  and  appropriate 
‘pipeline’  training  events. 

•  Solution  Management.  The  team  would  be  responsible  for  testing  FM 
Micro  Solutions  before  release  for  utilization  across  the  community. 

•  Training.  This  team  would  have  the  balance  of  technical  skills  to  needed 
to  provide  an  FM-focused  entry  level  Excel  VBA  course.  This  course 
would  focus  on  standing  up  applications  quickly  by  covering  commonly 
used  development  techniques.  The  training  could  be  tailored  to  the  need 
of  the  students  and  or  situation. 

•  Development  and  Development  Support.  The  team  would  have  the 
functional  and  technical  skills  available  to  develop  solutions  that 
presented  the  best  return,  based  on  outputs  provided  from  the  MSDM. 
The  team  could  also  serve  as  an  informal  ‘maintenance’  agency,  refining 
and  building  on  existing  solutions  driven  by  inputs  from  the  field. 
Finally,  the  team  would  provide  support  services  to  FM  Developers  in  the 
field  who  were  engaged  in  solution  development. 
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B.  ADDRESS  IN  POSTGRADUATE  EDUCATION 

Another  opportunity  for  realizing  value,  as  modeled  in  this  report,  is  found  in 
postgraduate  education.  Specifically,  the  introduction  of  advanced  Excel  application  and 
Excel  VBA  course  offerings  at  the  Air  Force  Institute  of  Technology  (AFIT)  and  the 
Naval  Postgraduate  School  (NPS).  These  courses  would  be  an  excellent  addition  in 
business -focused  programs,  such  as  Contracting,  Logistics,  and  Financial  Management, 
where  use  of  the  Excel  application  is  prevalent.  This  next  -level  approach  to  application 
training  is  a  great  opportunity  to  equip  students  with  important  technical  skills,  or  at  a 
minimum  make  field  leaders  aware  of  Excel  VBA  potential.  The  demand  for  IT  skills  in 
the  government  has  expanded  outside  the  traditional  functional  boundaries  as  we  have 
become  increasingly  resource  constrained. 


Top  Ten  Business  Schools  (Ranked  by 
Forbes) 

VBA 

Course 

#  of  IT 
classes 

IT 

Concentration 

Harvard 

1 

10 

No 

Columbia 

0 

0 

No 

Chicago 

0 

0 

No 

Dartmouth 

0 

0 

No 

Yale 

0 

0 

No 

Penn 

2 

11 

Yes 

Stanford 

1 

12 

Yes 

UNC 

0 

2 

No 

Northwestern 

0 

1 

No 

Virginia 

0 

0 

No 

Table  2.  IT/VBA  Emphasis  in  Top  Ten  Business  Schools  (U.S.) 


The  authors  looked  at  the  top  MBA  programs  to  see  what  training  they  were 
offering  in  this  area;  wc  evaluated  the  Information  Technology  emphasis  of  the  MBA 
programs  in  the  top  ten  business  schools,  as  ranked  by  Forbes  Magazine16.  Among  the 
top  programs,  five  had  required  courses  in  information  technology,  three  had  VBA 
elective  courses,  and  two  of  the  programs  offered  an  IT  concentration.  So  what 
conclusions  could  be  drawn  from  this?  It’s  an  emerging  field  in  the  business  schools. 


16  Forbes  Magazine,  September  2003.  Accessed  on  31  October  2005,  available  at 
www.forbes.com/2003/09/24/bschooland.html.  Internet. 
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Many  schools  are  focusing  on  the  managerial  level  and  are  placing  less  emphasis  on 
technology  side.  Table  2  displays  the  rankings  and  characteristics  of  each  program. 

Though  the  academic  community,  like  operations  in  the  field,  is  clearly  divided 
along  functional  lines  (IT  vs.  FM),  we  still  see  an  increasing  need  for  DoD  professionals 
who  possess  a  degree  of  skill  in  leveraging  common  business  applications.  We’re  often 
called  on  to  do  more  with  less,  and  we  must  become  smart  about  the  way  we  live  within 
today’s  infrastructure,  today.  The  MSDM  highlights  the  investment  potential  of  ‘grass¬ 
roots’  solutions,  but  for  solutions  to  be  developed  and  supported  in  the  field  they  must  be 
understood  and  supported  by  leadership.  Offered  an  Excel  VBA  course  as  an  elective 
provides  the  field  leader  an  opportunity  to  work  through  the  development  process  of  a 
small  project.  Not  only  would  the  student  gain  a  better  understanding  of  the  Excel 
application,  but  such  a  course  would  provide  a  practical  basis  for  developing  leaders  who 
will  someday  lead  large-scale  system  implementation  projects. 
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